Reducing data loss in remote databases

ABSTRACT

Systems and methods for reducing data loss in remote databases. One method includes detecting, with an electronic processor communicatively coupled to the remote database, a failure of a user session with the remote database. The method includes, in response to determining the failure of the user session, performing, with the electronic processor, an offline detection check for the user session, the offline detection check including a canary check on a known resource related to the remote database. The method includes, in response to the offline detection check indicating that the remote database is offline, setting the user session to read-only, displaying, within a graphical user interface of the user session, an offline indicator, and graphically marking the at least one outstanding request within the user session.

FIELD

Embodiments described herein relate to reducing data loss in remotedatabases and data services, and, more particularly, to handlingunresolved service requests at the end of a user session.

SUMMARY

Many users and organizations use cloud-based systems to enter and editdata, create, store, and edit documents, and the like. In such systems,documents and data are stored remotely from the user on a database andaccessed with, for example, a web-based application, a user may accessand use through a browser application. For example, a user may enterdata into the fields of a table of the remote database, which ispresented through the web-based application. However, when a user entersa value in a field representing a cell in a database record, thedatabase record does not match the entered value until the data presentin the field on the graphical user interface displayed by the browserapplication is written or committed to the database. In some instances,a user may attempt to exit the application before receiving confirmationthat the data is written to the database. This can lead toinconsistencies in or loss of data stored in the remote database.

To address this concern, some browser applications store a local versionof the data being edited or entered on a user device. However, somebrowser applications may not support this capability for security oradministrative reasons. For example, a shared public computing devicemay not allow local storage of such data. Furthermore, this approachonly maintains consistency with the remote database when (and if) aspecific client reconnects to the remote database at a later point. Forexample, if a user using a tablet computer closes a document beforechanges have been synchronized and then opens that same document on hisor her mobile phone, the user will not see the most recent changes. Thisapproach may lead to increased data inconsistency in multi-usercollaborative environments, where multiple clients store multipleversions of the data locally. However, restricting use of the data to asingle user (for example, where a document or table may be “checked out”by a user) to mitigate those issues inhibits collaboration among users.

Thus, embodiments described herein provide, among other things, systemsand methods for reducing data loss in remote databases. For example,when a user initiates a request to exit a user session with a remotedatabase (a request to exit a particular page or view presented within abrowser application or exit the entire user session), the browserapplication determines whether there are any outstanding requests (forexample, outstanding write requests) that must complete before exit. Ifthere are outstanding requests, the browser application presents adialog to the user. The browser application presents the dialog to theuser and waits for a predetermined period of time. When the time hasexpired, if the outstanding requests have been confirmed (for example,the write requests have all be fulfilled), then the browser applicationgrants the exit request. However, if there are still outstandingrequests, the browser application may display a second dialog. Thesecond dialog may communicate to the user an estimated time before theoutstanding write requests may be fulfilled, how significant the risk ofdata loss is (for example, depending on the type of data manipulationthat has not yet been committed), or the like. For example, the seconddialog may be based on a series of checks performed by the browserapplication regarding the state of the user's session. In particular,the browser application may determine the criticality, number, and typeof outstanding requests. The browser application may also use telemetrydata (for example, an average of the round trip times for the writerequests made during the current user session, other user sessions, or acombination thereof) and the number of outstanding requests to estimatethe time before the requests may be fulfilled. The second dialog mayinclude a selection mechanism for exiting the user session withoutwaiting for the outstanding requests to be fulfilled. As a result,embodiments described herein increase the likelihood that datamanipulations (edits, insertions, deletions, copies, and the like)entered through a browser application are committed upon exit, therebyreducing data loss in the remote database, while providing the user withcontrol and insight on whether to wait for the requests to be fulfilled.

As noted above, the browser application may estimate a time beforerequests are fulfilled based on telemetry data. In some embodiments, thetelemetry data is for the current user session, previous user sessionsassociated with the same user or a combination therefore. Also, in someembodiments, user session telemetry data, time estimates, or acombination thereof may be stored to a session metadata table for theremote database. Thus, in some embodiments, applications communicatingwith the remote database 104 may access this session metadata table toshare telemetry data, which can be used to provide dialogs to usersregarding when a session is safe to exit, manage workflow, or acombination thereof. Also, in some embodiments, user session telemetrydata, time estimates, or a combination may be shared betweenapplications directly, such as via an application programming interface(API). Using such embodiments, a browser application may estimate thetime needed to fulfill outstanding requests using telemetry data forother users that have or are performing similar operations under similarcircumstances.

In addition to or as an alternative to checking for outstanding requestswhen an exit request is received, embodiments described herein may alsoidentify when a user session has entered a degraded state (for example,when a user session has lost a connection to the remote database), andfurther reduce the likelihood of data loss by placing the table ordocument in a locked (read-only) state, which prevents the entry ofchanges that would be lost upon exit because they cannot be writtenremotely. Dialogs may also be presented to a user to inform the user ofthe identified degraded state, provide estimates of when a connectionmay be restored, inform a user of a degree of risk if a connectioncannot be reestablished, or a combination thereof. In some embodiments,a browser application is also configured to mark data manipulations,such as individual database cells or fields, that have not yet beencommitted to the remote database when a degraded state has beenidentified. Similar markings may also be used when an exit request isreceived as described above.

Accordingly, the embodiments described herein augment the userexperience with remote databases and other data and communicate the riskof data loss to a user (and, optionally, to other applications accessingthe remote database) in various conditions.

For example, one embodiment provides a system for reducing data loss ina remote database. The system includes at least one electronic processorcommunicatively coupled to the remote database. The at least oneelectronic processor is configured to receive a user input requesting toexit a user session with the remote database. The at least oneelectronic processor is configured to, in response to receiving the userinput, determine whether there is at least one outstanding request forthe user session. The at least one electronic processor is configuredto, in response to determining that there is at least one outstandingrequest for the user session, display a first dialog including a messageinforming a user to wait while the at least one outstanding request isbeing fulfilled. The at least one electronic processor is configured to,after a predetermined wait time has expired, determine whether the atleast one outstanding request has been fulfilled. The at least oneelectronic processor is configured to, in response to determining thatthe at least one outstanding request has not been fulfilled, perform arequest fulfillment check on the at least one outstanding request anddisplay a second dialog. The second dialog includes a message based onthe request fulfillment check informing the user of the at least oneoutstanding request and includes a control for exiting the user sessionwithout waiting for the at least one outstanding request to befulfilled.

Another embodiment provides a method for reducing data loss in a remotedatabase. The method includes detecting, with an electronic processorcommunicatively coupled to the remote database, a failure of a usersession with the remote database. The method includes, in response todetermining the failure of the user session, performing, with theelectronic processor, an offline detection check for the user session,the offline detection check including a canary check on a known resourcerelated to the remote database. The method includes, in response to theoffline detection check indicating that the remote database is offline,setting the user session to read-only, displaying, within a graphicaluser interface of the user session, an offline indicator, andgraphically marking the at least one outstanding request within the usersession.

A further embodiment provides a non-transitory computer-readable mediumincluding instructions executable by an electronic processor to performa set of functions. The set of functions includes receiving a user inputrequesting to exit a user session with a remote database. The set offunctions includes, in response to receiving the user input, determiningwhether there is at least one outstanding request for the user session.The set of functions includes, in response to determining that there isat least one outstanding request for the user session. The set offunctions includes, displaying a first dialog including a messageinforming a user to wait while the at least one outstanding request isbeing fulfilled. The set of functions includes, after a predeterminedwait time has expired, determining whether the at least one outstandingrequest has been fulfilled. The set of functions includes, in responseto determining that the at least one outstanding request has not beenfulfilled, displaying a second dialog. The second dialog includes amessage based on the at least one outstanding request and includes acontrol for exiting the user session without waiting for the at leastone outstanding request to be fulfilled.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates a system for accessing a remotedatabase according to some embodiments.

FIG. 2 is a block diagram of a server included in the system of FIG. 1according to some embodiments.

FIG. 3 is a flowchart illustrating a method for reducing data loss in aremote database using the system of FIG. 1 when an exit request isreceived according to some embodiments.

FIGS. 4A, 4B, and 5 illustrate a graphical user interface element foruse with the system of FIG. 1 according to some embodiments.

FIG. 6 is a flowchart illustrating a method for reducing data loss in aremote database using the system of FIG. 1 when a remote database may beoffline according to some embodiments.

FIGS. 7 and 8 illustrate a graphical user interface element for use withthe system of FIG. 1 according to some embodiments.

DETAILED DESCRIPTION

One or more embodiments are described and illustrated in the followingdescription and accompanying drawings. These embodiments are not limitedto the specific details provided herein and may be modified in variousways. Furthermore, other embodiments may exist that are not describedherein. Also, the functionality described herein as being performed byone component may be performed by multiple components in a distributedmanner. Likewise, functionality performed by multiple components may beconsolidated and performed by a single component. Similarly, a componentdescribed as performing particular functionality may also performadditional functionality not described herein. For example, a device orstructure that is “configured” in a certain way is configured in atleast that way, but may also be configured in ways that are not listed.Furthermore, some embodiments described herein may include one or moreelectronic processors configured to perform the described functionalityby executing instructions stored in non-transitory, computer-readablemedium. Similarly, embodiments described herein may be implemented asnon-transitory, computer-readable medium storing instructions executableby one or more electronic processors to perform the describedfunctionality. As used in the present application, “non-transitorycomputer-readable medium” comprises all computer-readable media but doesnot consist of a transitory, propagating signal. Accordingly,non-transitory computer-readable medium may include, for example, a harddisk, a CD-ROM, an optical storage device, a magnetic storage device, aROM (Read Only Memory), a RAM (Random Access Memory), register memory, aprocessor cache, or any combination thereof.

In addition, the phraseology and terminology used herein is for thepurpose of description and should not be regarded as limiting. Forexample, the use of “including,” “containing,” “comprising,” “having,”and variations thereof herein is meant to encompass the items listedthereafter and equivalents thereof as well as additional items. Theterms “connected” and “coupled” are used broadly and encompass bothdirect and indirect connecting and coupling. Further, “connected” and“coupled” are not restricted to physical or mechanical connections orcouplings and can include electrical connections or couplings, whetherdirect or indirect. In addition, electronic communications andnotifications may be performed using wired connections, wirelessconnections, or a combination thereof and may be transmitted directly orthrough one or more intermediary devices over various types of networks,communication channels, and connections. Moreover, relational terms suchas first and second, top and bottom, and the like may be used hereinsolely to distinguish one entity or action from another entity or actionwithout necessarily requiring or implying any actual such relationshipor order between such entities or actions.

As noted above, embodiments described herein provide one or morecomponents configured to identify various attributes of a user sessionwith a remote database or service, which can be used to balance the riskof data loss occurring and the amount of user dialogs a user sees. Forexample, FIG. 1 schematically illustrates a system 100 for accessing aremote database according to some embodiments. In the exampleillustrated in FIG. 1, the system 100 includes a server 102, a remotedatabase 104, and a user device 106. It should be understood that thesystem 100 is provided as an example and, in some embodiments, thesystem 100 may include additional components. For example, the system100 may include multiple servers 102, multiple remote databases 104,multiple user devices 106, or combinations thereof. In particular, itshould be understood that although FIG. 1 illustrates a single userdevice 106, the system 100 may include tens, hundreds, or thousands ofuser devices (used by associated users).

The server 102, the remote database 104, and the user device 106 arecommunicatively coupled via a communications network 108. Thecommunications network 108 may be implemented using a wide area network,such as the Internet, a local area network, such as a Bluetooth™ networkor Wi-Fi, a Long Term Evolution (LTE) network, a Global System forMobile Communications (or Groupe Spécial Mobile (GSM)) network, a CodeDivision Multiple Access (CDMA) network, an Evolution-Data Optimized(EV-DO) network, an Enhanced Data Rates for GSM Evolution (EDGE)network, a 3G network, a 4G network, and combinations or derivativesthereof.

As illustrated in FIG. 1, to provide the services described herein, theserver 102 communicates with the remote database 104. The remotedatabase 104 (or portions thereof) may be housed on a suitable databaseserver communicatively coupled to and accessible by the server 102. Insome embodiments, the remote database 104 is part of a cloud-baseddatabase system external to the system 100 and accessible by the server102 over one or more additional networks. Also, in some embodiments, theremote database 104 (or portions thereof) may be included in the server102. As also noted above, in some embodiments, the server 102 isconfigured to communicate with multiple remote databases 104.Furthermore, in some embodiments, the functionality described herein asbeing provided by the server 102 may be distributed over multipleservers.

Again, as noted above, embodiments described reduce data loss for theremote database 104 when the remote database 104 is accessed by a user,such as through a web application 110 operating on the server 102 thatthe user device 106 communicates with using a browser application 114.In some embodiments, the remote database 104 stores collaborative data115 (that is, data stored, retrieved, and edited by multiple usersworking in collaboration via the web application 110). For example, theweb application 110 may be a collaborative database tool that allowsmultiple users to access and edit a database. In another example, theweb application 110 may provide collaborative access and editing ofdocuments, stored in the remote database 104. For example, in someembodiments, the web application 110 is one of the Microsoft Office® 365suite of applications (for example, Outlook®, Word®, Excel®,PowerPoint®, and the like). It should be understood that in someembodiments, a user device 106 communicates with the web application 110using a dedicated client application in lieu of the browser application114. Furthermore, although the application 110 is referred to herein asa “web application,” the application 110 may be accessible by a userdevice 106 over any type of communications network 108 and is notlimited to Internet-enabled applications. Similarly, in someembodiments, the user device 106 may communicate with the application110 over a dedicated wired or wireless connection with the server 102.

As described in more detail below with respect to FIG. 3 and FIG. 6, thebrowser application 114 implements methods to prevent data loss in theremote database 104 as users (for example, the user 112) access and usethe web application 110. As illustrated in FIG. 1, the user 112 providesinputs and data to the web application 110 via the browser application114. The web application 110 opens a user session to the remote database104 to allow the user 112 to access and edit data from the remotedatabase 104. A user session may be, for example, a particular tableview of a database, a word processing document opened for editing, andthe like.

During a user session, the browser application 114, the server 102 (theweb application 110), or both gathers telemetry data (for example, datarelating to the quality and speed of the connection to the remotedatabase 104 via the web application 110) for the user session. Thecollected telemetry data may be stored locally on the user device 106,on the server 102, on the remote database 104, or a combination thereof.For example, as illustrated in FIG. 1, in some embodiments, telemetrydata is stored to a session metadata table 117 included in the remotedatabase 104. However, in other embodiments, the session metadata table117 (or portions thereof) may be stored in a data storage deviceseparate from the remote database 104. Applications communicating withthe remote database 104 may access the session metadata table 117 toshare telemetry data for user sessions with the remote database 104managed by one or more applications and use this telemetry data toestimate times, generate dialogs, manage workflow, or a combinationthereof. In some embodiments, applications can also similarly shareestimated times using the session metadata table.

In addition to or as an alternative to the session metadata table 117,applications may share telemetry data, estimated times, or the likeusing an application programming interface (API). The API may allow anapplication to access data stored in the session metadata table 117 ordirectly access data (telemetry data, estimated times, and the like)from other applications that interact with the remote application. Forexample, using the API, the browser application 114 can share telemetrydata, estimated times, and the like with an application 118 (forexample, executed by a computing device separate from the user device106 and the server 102) that also communicates with the remote database104. As noted above, this shared telemetry data and time estimationsallows an application to gain insight into the performance or workloadon the remote database 104, which can be used to generate dialogs,estimate times for fulfilling requests, identify when the remotedatabase 104 is offline or otherwise unavailable, manage workflow, andthe like.

In some embodiments, the browser application 114, the server 102 (theweb application 110), or both, monitor multiple user sessions to collecttelemetry data. In some embodiments, the telemetry data, time estimates,dialogs, and the like used by the browser application 114, the server102, or both may be based on similarities between the users.Similarities include, for example, whether the users are saving similardata, whether the users are being served by the same servers in the samedata centers, whether the users are being served concurrently with asimilar number of other users (that is, system load conditions), and thelike. In such embodiments, the system 100 can produce a model, which canestimate one user's likely duration based not only on data about thatuser but also on data gathered from other users' activities.

In some embodiments, the browser application 114, the server 102, orboth provide an administrative portal that can be used to enter andcustomize thresholds, metrics, timeouts, dialog language, and the likefor use with the methods described below with respect to FIG. 3 and FIG.6. In some embodiments, the administrative portal is included as part ofthe browser application 114, the web application 110, or both. However,in other embodiments, the administrative portal is a separateapplication executed by the user device 106, the server 102, or aseparate computing device. In some embodiments, other mechanisms may beused to apply settings (for example, an administrative script or anin-product option).

In addition to or as an alternative to the administrative portal, insome embodiments, various machine learning functions to can be used setthresholds, determine the risk of data loss, and generate dialogs, asdescribed herein that may otherwise be configurable through theadministrative portal. Machine learning generally refers to the abilityof a computer program to learn without being explicitly programmed. Insome embodiments, a computer program (for example, a learning engine) isconfigured to construct an algorithm based on inputs. Supervisedlearning involves presenting a computer program with example inputs andtheir desired outputs. The computer program is configured to learn ageneral rule that maps the inputs to the outputs from the training datait receives. Example machine learning engines include decision treelearning, association rule learning, artificial neural networks,classifiers, inductive logic programming, support vector machines,clustering, Bayesian networks, reinforcement learning, representationlearning, similarity and metric learning, sparse dictionary learning,and genetic algorithms. Using all of these approaches, a computerprogram can ingest, parse, and understand data and progressively refinealgorithms for data analytics.

The user device 106 is a personal computing device (for example, adesktop computer, a laptop computer, a terminal, a tablet computer, asmart telephone, a wearable device, or the like). As noted above, a useruses the user device 106 (the browser application 114 as executed by anelectronic processor) to access functionality provided by the server 102via the communications network 108. In particular, the browserapplication 114 establishes a user session with the remote database 104via the web application 110, which forms a communicative couplingbetween the browser application and the remote database 104. FIG. 2schematically illustrates the user device 106 in more detail. Asillustrated in FIG. 2, the user device 106 includes an electronicprocessor 202 (for example, a microprocessor, application-specificintegrated circuit (ASIC), or another suitable electronic device), astorage device 204 (for example, a non-transitory, computer-readablestorage medium), and a communication interface 206, such as atransceiver, for communicating over the communications network 108 and,optionally, one or more additional communications networks orconnections. It should be understood that the user device 106 mayinclude additional components than those illustrated in FIG. 2 invarious configurations and may perform additional functionality than thefunctionality described in the present application. For example, theuser device 106 also includes (or communicates with) one or more inputdevices, output devices, or a combination thereof, such as a keyboard, atouchscreen, a display device, a speaker, a microphone, or the like.Also, it should be understood that the functionality described herein asbeing performed by the user device 106 may be distributed among multipledevices, such as one or more servers and may be provided through a cloudcomputing environment, accessible by components of the system 100 viathe communications network 108.

The electronic processor 202, the storage device 204, and thecommunication interface 206 included in the user device 106 communicatewirelessly, over one or more communication lines or buses, or acombination thereof. The electronic processor 202 is configured toretrieve from the storage device 204 and execute, among other things,software for performing the control processes and methods describedherein (which may be included as part of the browser application 114).

The server 102 includes similar components as the user device 106 (anelectronic processor, storage device, and a communication interface). Itshould be understood that the functionality described herein as beingperformed by the user device 106 (or a portion thereof) may be performedat the server 102, such as via the web application 110 or a separateapplication or add-in. For example, the estimations, dialogs, checks,and related logic described herein as being performed by at the userdevice 106 (by the browser application 114) may be performed fully orpartially at the server 102 (by the web application 110). In particular,in some embodiments, the server 102 may have access to additionalinformation regarding the state of the remote database 104. However,performing logic at the server 102 may limit the use of such logic whenconnection between the user device 106 and the server 102 is slow orlost.

FIG. 3 illustrates an example method 300 for reducing data loss in aremote database when an exit request is received. The method 300 isdescribed as being performed by the user device 106 and, in particular,the electronic processor 202 executing the browser application. However,it should be understood that in some embodiments, portions of the method300 may be performed by other devices, including for example, the server102 as noted above. The method 300 is also described in terms ofreducing data loss for a single remote database 104 being accessedthrough the web application 110. However, it should be understood thatembodiments of the method 300 may be used for reducing data loss formultiple remote databases accessed through one or more applications.

As illustrated in FIG. 3, the browser application 114 receives a userinput requesting to exit a current user session with and the remotedatabase 104 (at block 302). Such an exit request may include a requestto leave a current page or view provided by the browser application 114or exit the entire user session. For example, an exit request may occurwhen a user clicks an exit button within the browser application 114,closes an open document within the browser application 114, exits from adatabase table within the browser application 114, selects the backbutton on the browser application 114, attempts to close the browserapplication 114, navigates to another context or view within the browserapplication 114, or the like.

In response to receiving the exit request, the browser application 114determines whether there is at least one outstanding request for theuser session (at block 304). As used herein, the term “outstandingrequest” refers to an uncommitted data entry, an unsynchronized dataentry, or both. An uncommitted data entry represents data (a datamanipulation) received from a user within the browser application 114,that has not be committed by the user for writing or synchronizationwith the remote database 104. For example, a user may have entered avalue into a database field but may have not pressed the enter key ormoved the cursor from the field to trigger a writing of the value to theremote database 104. In contrast, an unsynchronized data entryrepresents data (a data manipulation) received from a user within thebrowser application 114 that has been committed by the user for writingor synchronization with the remote database 104 but such synchronizationhas not yet completed (referred to herein as being “fulfilled”). In someembodiments, the browser application 114 maintains a queue of suchcommitted data entries or manipulations that have not yet beensynchronized with the remote database 104.

In some instances, a user may not have made any changes since their lastsave or changes may have been successfully synchronized with the remotedatabase 104 before the exit request is received. Accordingly, in thissituation, when there are no outstanding requests for the user session(at block 304), the user session is exited as requested (at block 306).Existing the user session may cause the browser application 114 on theuser device 106 to close or switch to a different new page.

Alternatively, when there is at least one outstanding request, exitingthe user sessions as requested by the user may result in data lossbecause data received from the user may not be successfully synchronizedwith the remote database 104. Accordingly, when the browser application114 determines that there is at least one outstanding request for theuser session (at block 304), the browser application 114 displays afirst dialog (at block 308). For example, as illustrated in FIG. 4A, afirst dialog 400 may include a message 402 informing the user thatchanges are being saved and advising the user to wait a short time. Insome embodiments, the first dialog does not include a mechanism forreceiving any type of user input (such as canceling the exit or forcingthe exit). The first dialog may be presented as a pop-up box or as anotification within a toolbar or other portion of a graphical userinterface provided via the browser application 114.

Returning to FIG. 3, when there is at least one outstanding request, thebrowser application 114 waits for the outstanding requests to complete.In particular, after a predetermined wait time has expired (at block310), the browser application 114 determines whether the at least oneoutstanding request has been fulfilled (at block 312). In someembodiments, the browser application 114 determines that a request hasbeen fulfilled by receiving a confirmation message or acknowledgmentfrom the remote database 104. In some embodiments, the predeterminedwait time is set to provide ample time for the outstanding requests tocomplete, but not so long that user frustration develops (for example, 5seconds). In some embodiments, the predetermined wait time is staticsuch that it does not depend on the user session, outstanding requests,or the like. In other embodiments, the predetermined wait time isdynamic such that depends on the user session, outstanding requests, orthe like. For example, in some embodiments, the predetermined wait timeis set based on an average network latency or other factors that mayaffect how long it may take for outstanding requests to complete, suchas a number of outstanding requests. Similarly, in some embodiments, thebrowser application 114 intelligently determines the predetermined waittime based on current and historical network conditions for the userdevice 106, session telemetry retrieved from the remote database 104,and the like.

When, after the predetermined wait time has elapsed, all of theoutstanding requests have been fulfilled (at block 312), the browserapplication 114 exits the user session as requested (at block 306). Insome embodiments, the browser application 114 exits the user session assoon as all of the outstanding requests have been fulfilled withoutwaiting for the predetermined wait time to elapse.

Alternatively, when, after the predetermined wait time has elapsed,there is still at least one outstanding request that has not beenfulfilled (at block 312), the browser application 114 performs a requestfulfillment check on the at least one outstanding request (at block314). The request fulfillment check is used to customize further dialogspresented to the user based on the outstanding requests that still havebeen be fulfilled as described below.

In some embodiments, the browser application 114 performs a requestfulfillment check by determining a request type for any outstandingrequests, a criticality for any outstanding requests, or both. Requesttypes may designate a type of data entry or manipulation that has notyet been synchronized with the remote database 104, such as inserting anew entry into a database field, changing the location of the cursorwithin a document, or the like. The criticality of a request maydesignate how important an outstanding request is, for example, ascompared to other outstanding requests, which may depend on the requesttype of an outstanding request. For example, a request to log a cursorlocation in a document file may not as critical as a request to updatethe format of a document, add a database schema, or other requests thatfundamentally change a document that may be shared among many users. Insome embodiments, each type of request may be associated with apredetermined criticality, which may be a numerical value or acategorization (low, medium, high).

In some embodiments, the browser application 114 may be built by adifferent software manufacturer than that of the server 102, database104, or both. In such embodiments, the request fulfillment checkperformed by the browser application 114 (and the ability to process theresponse) may be made through a documented API call. Such embodimentsmay include further APIs for sending and receiving the user sessiontelemetry data. In some embodiments, the business logic used to governthe user experience may be provided in a library provided by thesoftware vendor(s) of the server 102, the remote database 104, or both,or such logic may be built by the browser application's author, or byanother party.

Alternatively or in addition, the browser application 114 may perform arequest fulfillment check by determining whether an outstanding requestis conditionally chained to the success of another of outstandingrequest. For example, a request to input data into a new row for a tableis conditioned on successfully adding the row to the table. When theinitial request to create the row is not fulfilled, attempts tosynchronize data for that row will likely not succeed. This informationmay allow the browser application 114 to better estimate a time neededto fulfill the remaining outstanding requests.

Alternatively or in addition, the browser application 114 may perform arequest fulfillment check by determining a data loss risk level for theuser session, which may be based on the request type, criticality,conditioning chain, or combination thereof of each outstanding requestas described above. The data loss risk level indicates how likely it isthat data may be lost or how much data may be lost if the outstandingrequests are not fulfilled. For example, in some embodiments, thebrowser application 114 determines a data loss risk level based onrequested schema changes to the remote database 104, a quantity ofconditionally chained outstanding requests, an estimated time to fulfillthe outstanding request or requests, or a combination thereof. Forexample, when a high quantity of chained outstanding requests exists,the likelihood of data loss may increase because some of the requestscannot be attempted until others are fulfilled. In contrast, a quantityof non-chained requests may be completed in parallel, which may takeless time and, thus, decrease the possibility of data loss.

Similarly, in some embodiments, the browser application 114 uses theestimated time to fulfill the outstanding requests to determine the dataloss risk level (for example, the longer the estimated time, the higherthe risk that some data may be lost and, hence, the higher the risklevel). In some embodiments, the browser application 114 determines theestimated time based on telemetry data for the user session. Thetelemetry data may include a duration for a recently-fulfilled requestfor the user session, an average duration of two or more fulfilledrequests for the user session, a measure of network latency (forexample, a round trip time), browser processing delays, or the like.Processing delays may be caused by processing on the browser application114 on the user device 106 (for example, complex analysis operationsperformed in JavaScript™, photo upload functions, and the like). In someembodiments, the browser application 114 may also receive telemetry datafor other applications communicating with the remote database 104separate from the user session (for example, from the remote database104 or through an API). For example, as described above, in someembodiments, when the browser application 114 determines the estimatedtime, the browser application 114 shares the telemetry data, theestimated time, or both to a second application (for example, theapplication 118). As also described above, the browser application 114may share this information by storing the information in a table orother data structure accessible by the second application, via an API,or a combination thereof. In some embodiments, the server 102 mayindicate, for example, via an API, that it is under heavy load. It maybe that load is experienced in one region but not another. In suchinstances, the browser application 114 may respond a user's request toexit by attempting to send any outstanding requests to a different datacenter for that service.

Based on the results of the one or more request fulfillment checks, thebrowser application 114 displays a second dialog based on the requestfulfillment check (at block 316). FIG. 4B illustrates one example ofsuch a second dialog. As illustrated in FIG. 4B, in some embodiments,the second dialog 404 includes a message 406 and, optionally, a control(selection mechanism) that allows a user to choose whether to wait forthe outstanding requests to be fulfilled or, alternatively, force therequest exit. For example, as illustrated in FIG. 4B, in someembodiments, the second dialog 404 may include an exit confirmationcontrol 408 and a continuation control 410. The exit confirmationcontrol 408 allows the user to disregard the risk and exit as originallyrequested (at block 302). The continuation control 410 allows the userto stay in the current user session (in the embodiment illustrated, tostay in a table). It should be understood that the controls for forcingan exit may be active or passive. For example, in some embodiments, thesecond dialog may include one or more controls (selection mechanism)that allow a user to actively wait or actively exit the user session. Inother embodiments, the second dialog may inform the user of a defaultaction (waiting or exiting) that may be performed automatically unlessthe user provide contrary input via one or more controls. In someembodiments, the second dialog is displayed until all outstandingrequests are fulfilled or until a user takes an action, such as byclosing the dialog or selecting one of the controls. However, regardlessof how long the second dialog is displayed, the second dialog may beupdated at various events or on a predetermined frequency to provide auser with any updated information, such as an updated estimated time tofulfill the outstanding requests, the number or types of requestsremaining unfulfilled, or the like. In some embodiments, whencriticality is low, no dialog may be produced to provide a better userexperience. However, in some embodiments, when criticality is higher,then a dialog box is presented showing, for example, “this processtypically takes 3 seconds,” to reduce user confusion as to whether theyare being asked to wait indefinitely.

In some embodiments, message included in the second dialog provides moregranular information to the user regarding the outstanding requests,such as, for example, the request type, criticality, estimated data,data loss risk level, number of outstanding requests, number ofoutstanding requests with conditional chains, or a combination thereof.Alternatively or in addition, the message included in the second dialogmay be based on one or more of these characteristics. For example, thesecond dialog may include a different message based on the data lossrisk level, the estimated time, or the like. In particular, when thedetermined data loss risk level is high (greater than a predeterminedthreshold), the message included in the second dialog may inform theuser that there is a high risk of data loss if the user exits now, forexample, “You will likely lose the last 10 seconds of your work if youexit now. Please wait while we finish saving changes.”

In some instances, a user may have entered errant or otherwise invaliddata into a field or document via the browser application 114 but theentry may be included as one of the outstanding requests, such as one ofthe uncommitted entries. Accordingly, to prevent delaying an exitrequest due to invalid data (which should not be synchronized with theremote database 104 anyway), the browser application 114 may beconfigured to identify any such invalid data in response to receiving anexit request. For example, in some embodiments of the method 300, uponreceiving a request to exit, the browser application 114 performs avalidity check on any outstanding requests (for example, uncommitteddata entries). In particular, when the outstanding requests include atleast one uncommitted data entry, the browser application 114 maydetermine whether the at least one uncommitted data entry is valid. Thebrowser application 114 may make this determination by comparing thedata entry to a data template or other ruleset to determine whether thedata entry is valid given its context (for example, valid for a specificfield in a table). In some embodiments, in response to determining thatan uncommitted data entry is invalid (for example, was a characterstring rather than a numerical value), the browser application 114graphically marks the uncommitted data entry. For example, data enteredor modified within the graphical user interface displayed as part of theuser session may be graphically marked with highlighting, animation(blinking or flashing highlighting or content), bolding, or the like. Insome embodiments, the browser application 114 also displays an invaliddata dialog (see FIG. 5). The invalid data dialog may inform the userthat the marked data is invalid and, thus, will not be synchronized withthe remote database 104. In some embodiments, the invalid data dialogalso includes a mechanism where a user can cancel the exit (to correctthe invalid data) or confirm the exit. In other embodiments (if the onlyremaining outstanding requests include invalid data as described above),the browser application 114 may be configured to exit without committingsuch invalid data (for example, without marking the data) but may beconfigured to display a dialog informing the user that such invalid datawill not be committed.

As noted above, in some embodiments, in addition to or as an alternativeto tracking outstanding requests in response to receiving an exitrequest, the system 100 may be configured to detect degraded states of auser session and take one or more actions to prevent or reduce the riskof data loss. For example, FIG. 6 illustrates an example method 600 forreducing data loss in a remote database when the remote database 104 maybe offline (or otherwise unavailable). The method 600 is described asbeing performed by the user device 106 and, in particular, theelectronic processor 202 executing the browser application 114. However,it should be understood that in some embodiments, portions of the method600 may be performed by other devices, including for example, the server102. The method 600 is also described in terms of reducing data loss fora single remote database 104 using a single web application 110.However, it should be understood that embodiments of the method 600 maybe used for reducing data loss for multiple remote databases accessedvia one or more applications.

As illustrated in FIG. 6, in the method 600, the browser application 114detects a failure of a user session (at block 602). In some embodiments,the browser application 114 detects such a failure by detecting afailure of an outstanding request associated with the user session. Thebrowser application 114 may determine that the outstanding request hasfailed by comparing a pending time for the outstanding request to apredetermined threshold (for example, an estimated completion time forthe request). In another example, the browser application 114 determinesthat the outstanding request has failed when the browser application 114receives a failure indication (for example, from the remote database104). In some embodiments, the browser application 114 detects a failureof a user session only when a failure occurs for at least two of aplurality of outstanding requests (that is, there are multiplefailures). Similarly, in some embodiments, the browser application 114detects a failure of a user session only when one or more failures ofoutstanding requests are detected within a predetermined time window.Also, in some embodiments, the browser application 114 detects a failureof a user session when a queue of outstanding requests exceeds aparticular size or number of requests (for example, regardless ofwhether any such requests have failed). For example, a large queue ofoutstanding requests may indicate that delays or other errors areoccurring (even if just intermittently) even if requests are beingsuccessfully fulfilled. It should be understood that, in someembodiments, outstanding requests may also include other types ofrequests or activities separate form data entries (writing data back tothe remote database). For example, a request to log in to the webapplication 110 via the browser application 114 may be a request thatcan time out or result in a failure (for example, when a profile for theuser is not available or otherwise cannot be fetched). Thus, detecting afailure of a user session as described herein is not limited toidentifying failed or queued requests for data entries.

When the browser application 114 detects a failure of a user session,the browser application 114 performs an offline detection check (atblock 604). The offline detection check determines whether the remotedatabase 104 is offline or otherwise unreachable (for example, theconnection to the remote database 104 has been lost). In someembodiments, as part of the offline detection check, the browserapplication 114 performs a “canary check” on a known resource related tothe remote database 104. For example, the browser application 114 mayping the server 102 hosting the remote database 104 or attempt to open aconnection to another known service operating on the same server 102 asthe remote database 104. When one or more these canary checks fail (noresponse is received within a predetermined time period), the browserapplication 114 may determine that the remote database 104 is offline orotherwise unavailable.

In response to the offline detection check indicating that the remotedatabase 104 is offline (at block 606), the browser application 114 setsthe user session to read-only (at block 610). For example, a databasetable or document currently opened by a user via the browser application114 may be locked so that data can be read by the user but the usercannot make any edits or other data manipulations. In particular,because such data manipulations cannot be synchronized while the remotedatabase 104 is offline, the browser application 114 prevents the userfrom making further entries to prevent outstanding requests from queuingup while the remote database 104 is offline, which limits the risk ofdata loss. In some embodiments, a user may still be allowed tomanipulate the data but may be informed that such manipulations may notbe synchronized with the remote database 104. For example, to inform theuser of the read-only state of the user session, the browser application114 may display an offline indicator (at block 612). As illustrated inFIG. 7, an offline indicator 700 may include a message 702 displayedwithin a toolbar or message bar. In some embodiments, the offlineindicator also includes a control (selection mechanism) 704 that allowsthe user to force the browser application 114 to continue to checkwhether the remote database 104 is online or available again. In someembodiments, the browser application 114 may continue (at apredetermined frequency) to issue canary checks and may switch the usersession back to a live or read-write session in response to a successfulcanary check. For example, the browser application 114 may be configuredto retry outstanding requests with the remote database 104 (in a properorder according to condition chaining between requests as describedabove) in response to receiving a valid response to a canary check. Insome embodiments, the frequency of canary checks or retries after avalid response to a canary check is received may be determined based onthe outstanding requests, such as the number of requests, types ofrequests, estimated time, or the like, which the browser application 114may determine as described above with respect to FIG. 3. Accordingly,the control 704 may also a user to force a new canary check or a retry.

In some embodiments, the browser application 114 also graphically marksmodifications made by a user that have not been synchronized with theremote database 104 (at block 614). For example, any uncommitted orunsynchronized data displayed within a graphical user interfacepresented within the user session (data entries or edits) may begraphically marked as described above with respect to detected invaliddata. Providing such graphical markings allows a user to see what edits(data manipulations) have and have not been successfully synchronizedwith the remote database 104, which may inform the user whether therisks of data loss warrants waiting for the remote database 104 to comeback online or exiting the user session. Accordingly, it should beunderstood that such graphical markings may also be used with the method300 of FIG. 3, to inform a user of what data entries have not besynchronized with the remote database 104 when the user requested theexit.

Returning to FIG. 6, alternatively, when the browser application 114determines that the remote database 104 is not offline (at block 606),the browser application 114 determines whether there are any outstandingrequests that have not yet been fulfilled (at block 616). For example,in cases of intermittent connectivity, some requests may have completedbetween an initial failure or offline state of the remote database 104and the completion of the offline check (at block 606). When there areat least one outstanding request that has not been fulfilled (at block616), the browser application 114 may also set the user session toread-only (at block 618), as described above. For example, if there havebeen failures to prompt an offline check and outstanding requests arestill queued even through the remote database 104 is online, the browserapplication 114 may still switch the user session to the read-only modeto allow these queues requests to complete and also avoid further dataloss that may occur if failure continue to occur. To inform the user ofthe read-only state of the user session, the browser application 114 maydisplay a delay indicator (at block 620). As illustrated in FIG. 8, adelay indicator 800 may be similar to the offline indicator describedabove and may inform the user that some delays or intermittent failureshave been detected and, hence, the user session is being placed in theread-only mode as a precaution. In some embodiments, as illustrated inFIG. 8, the delay indicator 800 also includes a control 804 that allowsthe user to force the browser application 114 to continue to check for aconnection to the remote database 104 for completing the queueoutstanding requests (for example, forced canary check as describedabove). In some embodiments, the browser application 114 alsographically marks data associated with outstanding requests (at block622) as described above.

As illustrated in FIG. 6, when the remote database 104 is not offline(at block 606) and no outstanding requests have been queued (at block616), the browser application 114 may maintain the current state of theuser session but may continue to check for failures as described above(at block 602).

Thus, embodiments provide, among other things, systems and methods forreducing data loss in a remote database or other remotely-accessiblesystems and services. For example, as described above, suchremotely-accessible systems and services pose a risk of data loss when auser session is exited before all outstanding requests have beenfulfilled. Although, the exit can be hung while the requests arefulfilled, this process fails to give users control and insight intoexit delays and may waste computer resources waiting. Accordingly,embodiments described herein provide various checks and estimationprocesses (performed at the user device) to prevent data loss. Thesechecks can be used when an exit request is received as well as when thestate of a user session degrades, such as when a connection to theremote database is lost or the remote database is otherwise unavailable.Telemetry data associated with users sessions can be used to provide auser with estimations of how long it will take for data to besynchronized or the likelihood of data synchronizations completingsuccessfully. Such telemetry data may also be shared with otherapplications that may access the remote database, such as via an API. Asnoted above, although embodiments are described herein with reference toremote database, the methods and systems described herein may be usedwith other types of remotely-accessible services and systems, includingfor example, document processing services, messaging services, or thelike.

Various features and advantages of some embodiments are set forth in thefollowing claims.

What is claimed is:
 1. A system for reducing data loss in a remotedatabase, the system comprising: at least one electronic processorcommunicatively coupled to the remote database and configured to receivea user input requesting to exit a user session with the remote database;in response to receiving the user input, determine whether there is atleast one outstanding request for the user session; in response todetermining that there is at least one outstanding request for the usersession, display a first dialog including a message informing a user towait while the at least one outstanding request is being fulfilled;after a predetermined wait time has expired, determine whether the atleast one outstanding request has been fulfilled; and in response todetermining that the at least one outstanding request has not beenfulfilled, perform a request fulfillment check on the at least oneoutstanding request; and display a second dialog, the second dialogincluding a message based on the request fulfillment check informing theuser of the at least one outstanding request and including a control forexiting the user session without waiting for the at least oneoutstanding request to be fulfilled.
 2. The system of claim 1, whereinthe at least one outstanding request includes at least one selected froma group consisting of an uncommitted data entry and an unsynchronizeddata entry.
 3. The system of claim 1, wherein the at least oneelectronic processor is further configured to, in response to receivingthe user input, when the at least one outstanding request includes atleast one uncommitted data entry, determine whether the at least oneuncommitted data entry is valid; and in response to determining that theat least one uncommitted data entry is not valid, graphically mark theuncommitted data entry, and display an invalid data dialog.
 4. Thesystem of claim 1, wherein the at least one electronic processor isconfigured to perform the request fulfillment check by determining atleast one selected from a group consisting of a request type for the atleast one outstanding request and a criticality for the at least oneoutstanding request.
 5. The system of claim 1, wherein the at least oneelectronic processor is configured to perform the request fulfillmentcheck by, when the at least one outstanding request includes a pluralityof outstanding requests, determining whether any of the plurality ofoutstanding requests is conditionally chained to the success of anotherof the plurality of outstanding requests.
 6. The system of claim 1,wherein the at least one electronic processor is configured to performthe request fulfillment check by determining a data loss risk level forthe user session based on the at least one outstanding request.
 7. Thesystem of claim 6, wherein the at least one electronic processor isconfigured to determine the data loss risk level based on at least oneselected from a group consisting of requested schema changes to theremote database, a quantity of conditionally chained outstandingrequests, and an estimated time to fulfill the at least one outstandingrequest.
 8. The system of claim 1, wherein at least one electronicprocessor is configured to perform the request fulfillment check bydetermining an estimated time to fulfill the at least one outstandingrequest based on telemetry data for the user session.
 9. The system ofclaim 8, wherein the telemetry data is at least one selected from agroup consisting of a duration for a recently-fulfilled request for theuser session and an average duration of two or more fulfilled requestsfor the user session.
 10. The system of claim 8, wherein at least oneelectronic processor is further configured to transmit to a secondapplication accessing the remote database at least one selected from thegroup consisting of the telemetry data and the estimated time.
 11. Amethod for reducing data loss in a remote database, the methodcomprising: detecting, with an electronic processor communicativelycoupled to the remote database, a failure of a user session with theremote database; in response to determining the failure of the usersession, performing, with the electronic processor, an offline detectioncheck for the user session, the offline detection check including acanary check on a known resource related to the remote database; and inresponse to the offline detection check indicating that the remotedatabase is offline, setting the user session to read-only, displaying,within a graphical user interface of the user session, an offlineindicator, and graphically marking the at least one outstanding requestwithin the user session.
 12. The method of claim 11, further comprising:in response to the offline detection check indicating that the remotedatabase is online, determining whether the at least one outstandingrequest has been fulfilled; and in response to determining that the atleast one outstanding request has not been fulfilled, setting the usersession to read-only.
 13. The method of claim 11, wherein detecting thefailure of the user session includes detecting a failure of at least oneselected from a group consisting of an uncommitted data entry and anunsynchronized data entry.
 14. The method of claim 11, wherein detectingthe failure of the user session includes comparing a pending time forthe at least one outstanding request to a predetermined threshold. 15.The method of claim 11, wherein detecting a failure of the user sessionincludes detecting a failure of at least two of a plurality ofoutstanding requests.
 16. Non-transitory computer-readable mediumincluding instructions executable by an electronic processor to performa set of functions, the set of functions comprising: receiving a userinput requesting to exit a user session with a remote database; inresponse to receiving the user input, determining whether there is atleast one outstanding request for the user session; in response todetermining that there is at least one outstanding request for the usersession, displaying a first dialog including a message informing a userto wait while the at least one outstanding request is being fulfilled;after a predetermined wait time has expired, determining whether the atleast one outstanding request has been fulfilled; and in response todetermining that the at least one outstanding request has not beenfulfilled, displaying a second dialog, the second dialog including amessage based on the at least one outstanding request and including acontrol for exiting the user session without waiting for the at leastone outstanding request to be fulfilled.
 17. The non-transitorycomputer-readable medium of claim 16, the set of functions furthercomprising determining an estimated time to fulfill the at least oneoutstanding request based on telemetry data for the user session,wherein the message includes the estimated time.
 18. The non-transitorycomputer-readable medium of claim 17, the set of functions furthercomprising sharing at least one selected from a group consisting of thetelemetry data and the estimated time with an application communicatingwith the remote database separate from the user session.
 19. Thenon-transitory computer-readable medium of claim 18, wherein sharingincludes storing at least one selected from a group consisting of thetelemetry data and the estimated database to a table accessible by theapplication.
 20. The non-transitory computer-readable medium of claim18, wherein sharing includes communicating at least one selected from agroup consisting of the telemetry data and the estimated database withthe application via an application programming interface.